Asynchronous network stack operation in an operating system independent environment

ABSTRACT

Techniques for operation of an asynchronous stack in a pre-boot environment. A token-based stack design may be used to support communications between network stack layers.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a National Phase application of, and claims priorityto, International Application No. PCT/CN2005/000265, filed Mar. 5, 2005,entitled: “ASYNCHRONOUS NETWORK STACK OPERATION IN AN OPERATING SYSTEMINDEPENDENT ENVIRONMENT”

TECHNICAL FIELD

Embodiments of the invention relate to network stack operation Moreparticularly, embodiments of the invention relate to uses of anasynchronous network stack that may be used in an operating systemindependent (e.g., pre-boot) environment.

BACKGROUND

The pre-boot environment of an electronic device may be used for remoteboot and/or remote installation purposes, which may require theelectronic device to download one or more files from a remote serverbefore control of the electronic device is passed to an operatingsystem. In the pre-boot execution environment (PXE), the electronicdevice may receive one or more files form one or more remote servers.However, as the number of files downloaded increases and/or thefunctionality of the PXE increases, the current synchronous interfacefor packet transmission and receipt may become a bottleneck to systemperformance. Thus, current techniques for uploading and downloading ofdata in the PXE do not provide optimal performance.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are illustrated by way of example, and notby way of limitation, in the figures of the accompanying drawings inwhich like reference numerals refer to similar elements.

FIG. 1 is a conceptual block diagram of one embodiment of anasynchronous network stack that operates using a token.

FIG. 2 is a block diagram of one embodiment of an embedded firmwareagent.

FIG. 3 is a conceptual flow diagram of one embodiment of a token passingsequence between layers in an asynchronous network stack.

FIG. 4 is a conceptual flow diagram of one embodiment of a sequencebetween layers in an asynchronous network stack to cancel a previouslyrequested/scheduled operation using a token.

FIG. 5 is a block diagram of one embodiment of an electronic system.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth.However, embodiments of the invention may be practiced without thesespecific details. In other instances, well-known circuits, structuresand techniques have not been shown in detail in order not to obscure theunderstanding of this description.

Described herein are techniques for asynchronous network stack operationin an operating system independent environment. In one embodiment, theasynchronous operation may be supported by a token-based stack designthat may be used for network communications in the pre-boot environment,or any operating system independent environment. The techniques providean asynchronous calling framework for network stack drivers thatrepresent various operational layers. In one embodiment, the driveractions (e.g., transmit receive) are schedulable.

Described herein are techniques for use of a token to support operationof the asynchronous network stack. In one embodiment, the token may havethe following four characteristics: 1) the token may identify arequested action (e.g., to transmit a data packet, to receive a datapacket), 2) a status indicator to indicate the current phase of thetoken or the result of the request, 3) an event to provide notificationof a status change, and 4) a context. In alternate embodiments,additional and/or different token characteristics may be supported.

FIG. 1 is a conceptual block diagram of one embodiment of anasynchronous network stack that operates using a token. The conceptualblock diagram of FIG. 1 includes specific network layers and protocols;however, in alternate embodiments different protocols and/or layers maybe supported.

In one embodiment, the physical implementation of each network layer maybe configured to communicate with embedded firmware agent 190. Inalternate embodiments, one or more of the layers may not be configuredto communicate with embedded firmware agent 190. Application 100 mayrepresent any type of application, whether under operating systemcontrol or not, that includes functionality to communicate over anetwork external to the host device. Application 190 may be any type ofapplication known in the art.

In one embodiment, Application 190 may request services, for example,transmission of a network packet, by passing a token to MulticastTrivial File Transfer Protocol layer 110. In general, TFTP is a transferprotocol that is simpler to use than the File Transfer Protocol (FTP),but provides less functionality. For example, TFTP does not support userauthentication or directory visibility. TFTP uses the User DatagramProtocol (UDP) rather than the Transmission Control Protocol (TCP). Oneembodiment of TFTP is described formally in Request for Comments (RFC)1350, Rev. 2, published July 1992.

TFTP has been expanded to include a multicast option as described in RFC2090, published February 1997. Multicast TFTP classifies client devicesas active clients or passive clients. There is only one active client ata time. The active client communicates with a server to download datausing a stop-and-wait ARQ flow and error control technique to anegotiated group address. When the requested activity has beenaccomplished, MTFTP layer 110 returns an event notification with thetoken requesting the activity. Use of the token and the eventnotification may allow application 190 to continue operation and engagein other tasks during the time required to accomplish the requestedactivity.

In one embodiment, the token passing technique may be employed betweeneach network stack layer. That is, between MTFTP layer 110 and UDP layer120, between UDP layer 120 and IP layer 130, between IP layer 130 andManaged Network Protocol (MNP) layer 140, and between MNP layer 140 andNIC driver 150.

In one embodiment, MTFTP layer 110, UDP layer 120, IP layer 130 and MNPlayer 140 may represent layered network drivers. In a synchronousnetwork stack, the calling layer will halt operation while the calledlayer performs the requested operation. In contrast, using theasynchronous network stack techniques described herein, a layer mayrequest an operation from a lower layer using a token and performoperations not dependent upon the requested operation while theoperation is being performed by the lower layer.

For example, IP layer 130 may request a received IP packet and mayprepare a receive token and an associated notify event. After passingthe receive token to MNP layer 140, IP layer 130 may engage in otheroperations, for example, preparation of a packet for transmission. Whena packet is received from the network and processed by MNP layer 240,the received packet may be stored and MNP layer 240 may notify IP layer140 of the received packet via an event with token received from IPlayer 140. In response to the event, IP layer 140 may process thereceived packet.

In one embodiment, embedded firmware agent 190 may allow theasynchronous network stack to operate in an operating system independentenvironment FIG. 2 is a block diagram of one embodiment of an embeddedfirmware agent. In the example of FIG. 2 the embedded firmware agent mayhave an interface compliant with an Extensible Firmware Interface (EFI)as defined by the EFI Specifications, version 1.10, published Nov. 26,2003, available from Intel Corporation of Santa Clara, Calif. Inalternate embodiments, other firmware components can also be used.

In one embodiment the embedded firmware agent may include agent bus 200coupled with system interface 205. System interface 205 may provide aninterface through which the embedded firmware agent communicates withthe host system. The embedded firmware agent may further include agentnetwork interface 250 that may be coupled with an external network (notshown in FIG. 2) to allow the embedded firmware agent to communicatewith a remote electronic device. Agent network interface 250 may supportwired and/or wireless network communications.

In one embodiment the embedded firmware agent further includes dynamicmemory 210 that may be coupled with agent bus 200. Dynamic memory 210may provide storage for instructions and/or data to be used duringoperation. The embedded firmware agent may further include non-volatilestorage 220 that may be coupled with agent bus 200 to store static dataand/or instructions. In one embodiment, the embedded firmware agent mayinclude control circuitry 230 coupled with agent bus 200 that mayperform control operations and/or execute instructions provided bydynamic memory 210 and/or non-volatile storage 220.

In one embodiment, the embedded firmware agent may support operationsthat are independent of the host operating system. These operations maybe, for example, pre-boot operations that are performed prior to theoperating system being loaded, or while the operating system is beingloaded, but prior to transfer of control to the operating system. Theseoperations may also be independent of the host operating system when thehost operating system has control of the host electronic device. Forexample, in one embodiment, the embedded firmware agent may be coupledwith a host processor via an interrupt interlace with, for example, theSMI pin of a Pentium® processor or with the PMI pin of an Itanium®processor (generically, xMI line). Other system interrupt signals may beused for other processors.

Because use of tokens as described herein may allow layer operations tobe schedulable, parallel technology including, for example,hyperthreading, multi-processor systems and multi-threading may beincorporated into the firmware level design and allow stack drivers toperform parallel operations. With use of, for example, an interrupt or atimer, an embedded firmware agent may interact with the asynchronousnetwork stack to enable network operations including, for example, abackground web server or a background telnet server, to be supported ina pre-boot or operating system independent environment. Use of statusand/or context mat may be supported by the token may allow network stacklayers to communicate status without use of other channels as may berequired by synchronous stack configurations.

FIG. 3 is a conceptual flow diagram of one embodiment of a token passingsequence between layers in an asynchronous network stack. In oneembodiment, the upper network stack may generate or prepare a token torequest a specific operation (e.g., transmission or receipt of apacket). In one embodiment, the token may include a notify event and/orcontextual information that may be used to communicate status or contextof the requested operation. In one embodiment, the upper stack layer maycall a method or function of the lower stack layer to pass the token tothe lower stack layer.

In response to receiving the token, the lower stack layer may performand/or schedule the operation requested (e.g., transmit, receive) withthe token. Upon completion of the requested operation, the lower stacklayer may generate or prepare a signal event that communicates thecompletion of the requested operation to the embedded firmware agent. Inone embodiment the embedded firmware agent may notify the upper stacklayer of completion of the requested operation with an eventnotification. In response to receiving the event notification, the upperstack layer may perform any operation completion handling and delete thetoken.

FIG. 4 is a conceptual flow diagram of one embodiment of a sequencebetween layers in an asynchronous network stack to cancel a previouslyrequested/scheduled operation using a token. In one embodiment, theupper network stack may generate or prepare a cancel request to cancel apreviously generated token. In one embodiment, the cancel request mayinclude the token and/or contextual information that may be used tocommunicate status or context of the token.

In one embodiment, the upper stack layer may call a method or functionof the lower stack layer to pass the cancel request to the lower stacklayer. In response to receiving the cancel request, the lower stacklayer may abort the previous operation identified by the token and thengenerate or prepare a signal event to embedded firmware agent. In oneembodiment the embedded firmware agent may transmit a dispatch eventsignal to the upper stack layer, which may cause the upper stack layerto perform any error handling and delete the token.

In one embodiment, the techniques of FIGS. 3 and 4 can be implemented asinstructions executed by an electronic system. The instructions may bestored by the electronic device or the instructions can be received bythe electronic device (e.g., via a network connection). FIG. 5 is ablock diagram of one embodiment of an electronic system. The electronicsystem illustrated in FIG. 5 is intended to represent a range ofelectronic systems, for example, computer systems, network accessdevices, etc. Alternative systems, whether electronic or non-electronic,can include more, fewer and/or different components. The electronicsystem of FIG. 5 may represent a server device as well as the one ormore client devices.

Electronic system 500 includes bus 505 or other communication device tocommunicate information, and processor 510 coupled to bus 505 to processinformation. While electronic system 500 is illustrated with a singleprocessor, electronic system 500 can include multiple processors and/orco-processors. Electronic system 500 further includes random accessmemory (RAM) or other dynamic storage device 520 (referred to asmemory), coupled to bus 505 to store information and instructions to beexecuted by processor 510. Memory 520 also can be used to storetemporary variables or other intermediate information during executionof instructions by processor 510.

Electronic system 500 also includes read only memory (ROM) and/or otherstatic storage device 530 coupled to bus 505 to store static informationand instructions for processor 510. In one embodiment, static storagedevice 530 may include an embedded firmware agent. In alternateembodiments, other firmware components can also be used.

Data storage device 540 is coupled to bus 505 to store information andinstructions. Data storage device 540 such as a magnetic disk or opticaldisc and corresponding drive can be coupled to electronic system 500.

Electronic system 500 can also be coupled via bus 505 to display device550, such as a cathode ray tube (CRT) or liquid crystal display (LCD),to display information to a user. Alphanumeric input device 560,including alphanumeric and other keys, is typically coupled to bus 505to communicate information and command selections to processor 510.Another type of user input device is cursor control 570, such as amouse, a trackball, or cursor direction keys to communicate directioninformation and command selections to processor 510 and to controlcursor movement on display 550. Electronic system 500 further includesnetwork interface 580 to provide access to a network, such as a localarea network. Network interface 580 may further include one or moreantennae 585 to provide a wireless network interface according to anyprotocol known in the art.

Instructions are provided to memory from a storage device, such asmagnetic disk, a read-only memory (ROM) integrated circuit CD-ROM, DVD,via a remote connection (e.g., over a network via network interface 580)that is either wired or wireless providing access to one or moreelectronically-accessible media, etc. In alternative embodiments,hard-wired circuitry can be used in place of or in combination withsoftware instructions. Thus, execution of sequences of instructions isnot limited to any specific combination of hardware circuitry andsoftware instructions.

An electronically-accessible medium includes any mechanism that provides(i.e., stores and/or transmits) content (e.g., computer executableinstructions) in a form readable by an electronic device (e.g., acomputer, a personal digital assistant, a cellular telephone). Forexample, a machine-accessible medium includes read only memory (ROM);random access memory (RAM); magnetic disk storage media; optical storagemedia; flash memory devices; electrical, optical, acoustical or otherform of propagated signals (e.g., carrier waves, infrared signals,digital signals); etc.

Reference in the specification to “one embodiment” or “an embodiment”means that a particular feature, structure, or characteristic describedin connection with the embodiment is included in at least one embodimentof the invention. The appearances of the phrase “in one embodiment” invarious places in the specification are not necessarily all referring tothe same embodiment.

While the invention has been described in terms of several embodiments,those skilled in the art will recognize that the invention is notlimited to the embodiments described, but can be practiced withmodification and alteration within the spirit and scope of the appendedclaims. The description is thus to be regarded as illustrative insteadof limiting.

1. A method comprising: sending a request for a first network operationfrom a first network stack layer to a second network stack layer using atoken-based asynchronous inter-layer communication protocol in anoperating system independent environment; performing, with the firstnetwork stack layer, a second network operation prior receiving anindication of completion of the first network operation; and sending theindication of completion of the first network operation from the secondnetwork stack layer to the first network stack layer via an embeddedfirmware agent in response to completion of the first network operation.2. The method of claim 1 wherein the first network stack operationcomprises a data transmission operation.
 3. The method of claim 1wherein the first network stack operation comprises receipt of data viaa network connection.
 4. The method of claim 1 wherein the operatingsystem independent environment comprises a pre-boot executionenvironment.
 5. The method of claim 1 wherein the first network stacklayer and the second network stack layer are both communicativelycoupled with an embedded firmware agent in a host system that supportsthe asynchronous token-based network stack.
 6. The method of claim 1wherein the indication of completion includes at least the token.
 7. Anapparatus comprising: an embedded firmware agent capable of functioningin an operating system independent manner; control circuitry to supporta token-based asynchronous inter-layer communication protocolcommunicatively coupled with the embedded firmware agent to send arequest for a first network operation from an upper network stack layerto a lower network stack layer using a request including a token,performing, with the upper network stack layer, a second networkoperation prior receiving an indication of completion of the firstnetwork operation, and send the indication of completion of the firstnetwork operation from the second network stack layer to the firstnetwork stack layer via an embedded firmware agent in response tocompletion of the first network operation.
 8. The apparatus of claim 7wherein the first network stack operation comprises a data transmissionoperation.
 9. The apparatus of claim 7 wherein the first network stackoperation comprises receipt of data via a network connection.
 10. Theapparatus of claim 7 wherein the operating system independentenvironment comprises a pre-boot execution environment.
 11. Theapparatus of claim 7 wherein the indication of completion includes atleast the token.
 12. An article comprising a computer-readable mediumhaving stored thereon instructions that, when executed, cause one ormore processing components to: send a request for a first networkoperation from a first network stack layer to a second network stacklayer using a token-based asynchronous inter-layer communicationprotocol in an operating system independent environment; perform, withthe first network stack layer, a second network operation priorreceiving an indication of completion of the first network operation;and send the indication of completion of the first network operationfrom the second network stack layer to the first network stack layer viaan embedded firmware agent in response to completion of the firstnetwork operation.
 13. The article of claim 12 wherein the first networkstack operation comprises a data transmission operation.
 14. The articleof claim 12 wherein the first network stack operation comprises receiptof data via a network connection.
 15. The article of claim 12 whereinthe operating system independent environment comprises a pre-bootexecution environment.
 16. The article of claim 12 wherein theindication of completion includes at least the token.
 17. A systemcomprising: one or more processing components; a network interfacecoupled with the one or more processing components; and acomputer-readable medium coupled with the one or more processingcomponents having stored thereon instructions that when executed, causethe one or more processing components to send a request for a firstnetwork operation from a first network stack layer to a second networkstack layer using a token-based asynchronous inter-layer communicationprotocol in an operating system independent environment, perform, withthe first network stack layer, a second network operation priorreceiving an indication of completion of the first network operation,and send the indication of completion of the first network operationfrom the second network stack layer to the first network stack layer viaan embedded firmware agent in response to completion of the firstnetwork operation.
 18. The system of claim 17 wherein the first networkstack operation comprises a data transmission operation.
 19. The systemof claim 17 wherein the first network stack operation comprises receiptof data via a network connection.
 20. The system of claim 17 wherein theoperating system independent environment comprises a pre-boot executionenvironment.